Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.coderabbit.yml:
- Around line 109-112: Add the repository-owned Semgrep config path under the
existing semgrep section so CodeRabbit loads .semgrep.yaml: in the
.coderabbit.yml semgrep block (the keys "semgrep" and "enabled") add a
"config_file: .semgrep.yaml" entry alongside enabled: true to explicitly point
CodeRabbit to the repository's Semgrep rules file.

In @.semgrep.yaml:
- Around line 185-199: Update the semgrep rule id
"delaunay.rust.no-production-unwrap-panic" to also match .expect(...) calls so
they cannot bypass the check: in the patterns.pattern-either array add a pattern
like "$VALUE.expect(...)" (mirroring the existing "$VALUE.unwrap()" entry) and
ensure the rule still applies to the same paths; this will catch production uses
such as the .expect("point was set before building vertex") in
src/core/vertex.rs::from_points and force returning typed errors instead of
panicking.

In `@justfile`:
- Around line 587-588: The semgrep-test target is running semgrep against a
fixture in tests/semgrep/... which doesn't match the rule's include pattern
(/src/core/algorithms/**), so the rule never runs; update the semgrep-test
target (symbol: semgrep-test) to ensure the fixture path is in-scope by either
running uv/semgrep from the tests/semgrep directory, adding the fixture path to
the scan arguments, or expanding the rule's include pattern (rule id:
delaunay.rust.no-std-hash-collections-in-hot-src) to also match
tests/semgrep/src/core/algorithms/** so the test actually exercises the rule.

In `@src/core/util/hilbert.rs`:
- Around line 456-457: The documentation for hilbert_indices_prequantized
incorrectly mentions returning HilbertError::QuantizationScaleConversionFailed
even though the function accepts pre-quantized u32 coordinates and never
performs any scalar/scale conversion; update the doc comment to remove that
error from the returns/errors list (or replace it with the correct possible
errors if any), and ensure any sentence that references "quantization grid
maximum cannot be represented by the coordinate scalar type" is deleted or
reworded to accurately reflect that hilbert_indices_prequantized operates on u32
inputs and does not perform scalar conversion.

In `@src/core/vertex.rs`:
- Around line 599-604: The public method from_points currently maps Points to
Vertices by calling VertexBuilder::default().point(*p).build().expect(...),
which can panic if build() gains error variants; replace this fragile path with
an infallible conversion: add or use an explicit constructor (e.g.,
Vertex::from_point or Vertex::new_from_point) that creates a Vertex directly
from a Point without using the fallible VertexBuilder::build(), then change
from_points to map each Point to that constructor (remove expect/unwrap). Ensure
the new constructor lives alongside Vertex/impl and is used by from_points so
the public API no longer can panic on valid input.

---

Outside diff comments:
In `@src/core/util/hilbert.rs`:
- Around line 553-578: Update the hilbert_sorted_indices documentation to list
the new possible error from hilbert_quantization_scale by adding
HilbertError::QuantizationScaleConversionFailed to the `# Errors` section;
locate the function hilbert_sorted_indices and its docs, and mention that
calling hilbert_quantization_scale::<T>(bits) can return
QuantizationScaleConversionFailed so it should be documented alongside the
existing InvalidBitsParameter, DimensionTooLarge, and IndexOverflow errors.
- Around line 15-16: Add the #[non_exhaustive] attribute to the HilbertError
enum declaration (the enum named HilbertError with #[derive(...)] ) so
downstream code cannot exhaustively match it; also update the
hilbert_sorted_indices function documentation to list
HilbertError::QuantizationScaleConversionFailed as a possible returned error
(since hilbert_sorted_indices calls hilbert_quantization_scale::<T>(bits)? which
can return that variant). Ensure both changes reference the existing symbols
HilbertError, hilbert_sorted_indices, and hilbert_quantization_scale::<T>(bits)
so reviewers can locate the edits.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@semgrep.yaml`:
- Around line 36-54: The listed pattern-not and pattern-not-regex exclusions
(e.g., entries matching "$TYPE::try_from($VALUE).expect(...)",
"$VALUE.to_f64().expect(...)", "NonZeroUsize::new($VALUE).expect(...)",
"build_facet_to_cells_map().expect(...)", and the expect("...") message
exclusions) are ineffective because they can never share the same AST position
as the println!/eprintln! matches; remove those pattern-not and
pattern-not-regex clauses from semgrep.yaml so the rule only contains meaningful
exclusions (keep any other valid filters but delete the shown expect-related
pattern-not and pattern-not-regex entries).

In `@src/geometry/util/triangulation_generation.rs`:
- Around line 100-101: The public docs' "# Panics" section is out of date
because Vertex construction is now infallible via Vertex::from_point and
Vertex::from_point_with_data; update the documentation for the affected
function(s) in triangulation_generation.rs to remove or revise any panic claims
and instead state that vertex construction is infallible (or document the real,
non-panicking conditions, if any). Locate references to Vertex::from_point and
Vertex::from_point_with_data in the function docs and replace the panic contract
with the current behavior (e.g., no panics on user input; describe returned
values/side-effects) to comply with the Result/No-panic guideline.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/geometry/algorithms/convex_hull.rs`:
- Around line 1904-1908: Replace unconditional println! calls in the test blocks
in convex_hull.rs (and the other listed ranges) with tracing macros and gate
them behind the test-debug feature: change println! to tracing::debug! or
tracing::info!, and wrap the diagnostics so they only run when the test-debug
feature is enabled (either via an if cfg!(feature = "test-debug") { ... } guard
or by putting the diagnostic statement inside a #[cfg(feature = "test-debug")]
block). Update imports to use tracing::{debug,info} where needed and ensure the
tests retain the same messages but no longer print unconditionally to stdout.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/core/util/hilbert.rs`:
- Around line 141-145: The code silently maps failed scaled.round().to_u32()
conversions to 0 (in the quantized assignment inside
hilbert_quantize_with_scale), which can corrupt Hilbert ordering; change this to
return a typed error instead of defaulting to 0 (propagate a
QuantizationScaleConversionFailed-like error from hilbert_quantize_with_scale)
or replace the map_or(0, ...) with an expect/assert that documents why a failure
is impossible; update the function signature to propagate the error (or add an
explicit panic message) and adjust callers of hilbert_quantize_with_scale
accordingly so conversion failures are not silently collapsed to zero.

---

Nitpick comments:
In `@src/core/util/hilbert.rs`:
- Around line 636-661: Add a regression test that exercises the new
QuantizationScaleConversionFailed error via the public API (e.g., call
hilbert_sorted_indices and/or hilbert_sort_by_unstable/hilbert_sort_by_stable)
and assert the call returns an Err variant matching
QuantizationScaleConversionFailed; construct input bounds/coordinates known to
trigger the conversion failure (use the public functions hilbert_sorted_indices,
hilbert_sort_by_unstable, or hilbert_sort_by_stable and check the returned
Result), and add the test alongside the existing hilbert tests so the error path
is pinned by CI.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/core/vertex.rs`:
- Around line 565-566: The constructor docs incorrectly claim an infallible
guarantee because `Point` is "already validated"; update the doc comment for the
`Vertex` constructor that accepts a `Point` (the `From<Point>`/`Vertex::from`
constructor) to remove the implication that `Point` holds only valid/finite
coordinates and instead state that the constructor is infallible because it does
not perform additional validation (so callers must ensure coordinates are
finite/validated if required); apply the same wording fix to the other doc block
mentioned around the second occurrence (lines noted in the review).